The Need for SoS Safety Cases

When you create a System of Systems (SoS), you are doing wilful design. It follows that you need a safety case: a justification of why that system will be safe. All safety cases must have certain common properties: they must focus on risk, they must provide appropriate confidence in their claims, and they must have a clear relationship to a causal model of the system's safety behaviour. None of those are particularly easy for SoS, and there are several areas where SoS are particularly problematic, such as what exactly "the system" comprises, and what on Earth its lifecycle actually is. On the other hand, not everything about SoS safety is necessarily hard, and not every problem faced in SoS safety is an "SoS problem". Motivation: have we got a case? A System of Systems (SoS) is a system composed of components that are themselves systems, and that have their own goals and some degree of autonomy, yet still remain part of a whole with some shared goals and management. When you create an SoS, you are doing wilful design. If you define a configuration of assets to achieve certain aims, and agree that they will communicate and coordinate in certain specific ways, then you are doing explicit, conscious design. When you allow personnel within an SoS to adopt a pattern of using a certain configuration of assets to achieve certain aims, and habitually coordinate their actions by specific patterns of communication, then you are doing implicit, passive design. Either way, you are responsible for the consequences of those design decisions, and could be held accountable if they lead to an accident which causes